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INTRODUCTION 

Starting from the 1980s, communications in industrial envi- 
ronments progressively switched to multipoint serial digital 
transmissions. The advantage of such a choice is mainly 
twofold: first, bundles of point-to-point analogue links were 
replaced by a shared communication support; second, remote 
configuration, management, and diagnostic operations were 
enabled, easily and effectively. The related solutions are usu- 
ally known as the fieldbuses. 

Currently, for industrial communication systems, con- 
vergence is taking place toward new technologies derived 
from the Information and Communication Technology (ICT) 
world. Synergies achieve increased performance and better 
interoperability while reducing design, implementation, and 
maintenance costs at the same time. In particular, two main 
trends have been followed so far. Concerning the aspects 
related to the lower layers of the communication protocol 
stack (i.e., network controllers, transceivers, physical com- 
munication support, and so on), proprietary technologies 
are being replaced by conventional Ethernet [1] also in the 
control networks used at the lowest level of factory automa- 
tion systems. At the upper layers, instead, the adoption of 
Transmission Control Protocol/Internet Protocol (TCP/IP) 
[2] as well as of the application-layer protocols usually found 
in Intranets is becoming more and more common in auto- 
mated industrial environments, too, in order to achieve an 
unprecedented degree of integration among the different sys- 
tems and equipment. 

Communication systems based on such a kind of archi- 
tecture are commonly referred to as industrial Ethernet. 
Sometimes, the term Real-Time Ethernet (RTE) is also used, 
but it mainly refers to the mechanisms put into effect for 
enabling real-time (RT) data exchanges over Ethernet. In 
the following, a number of popular solutions are taken into 
account for which equipment and devices are effectively 
available off-the-shelf. In particular, Modbus TCP, EtherNet/ 
IP, Ethernet Powerlink, and EtherCAT have been considered, 
in order to provide a significant outlook on the subject. First, 
a general classification scheme is introduced that defines a 
limited number of network classes that share similar fea- 
tures. Then, each network is described separately in the light 
of the above classification, so as to provide more details on its 
actual behavior and performance. 


TAXONOMY OF INDUSTRIAL ETHERNET SOLUTIONS 

When dealing with the industrial Ethernet solutions that are 
currently available off-the-shelf, it is possible to classify them 
in many different ways, as in reference [3]. In the follow- 
ing, a taxonomy is introduced that basically considers what 
and how much each solution retains of the communication 
subsystems currently used in office environments (based on 
Ethernet and intranet technologies). 

Generally speaking, three conformance classes can be 
defined, namely, 

• Class 1: Solutions that rely on both conventional 
Ethernet hardware and the standard TCP/IP commu- 
nication suite 

• Class 2: Solutions that rely on conventional Ethernet 
hardware but adopt specific mechanisms in the pro- 
tocol stack in order to improve performance and/or 
determinism 

• Class 3: Solutions that adopt modified hardware 
as well as specific protocol stacks so as to achieve 
increased performance and/or a higher degree of 
determinism. 

In any case, all the solutions rely on conventional 
Ethernet transceivers at the physical layer and adopt the stan- 
dard Ethernet frame format. Clearly, these are considered as 
basic requirements so that a given network can be referred to 
as industrial Ethernet. In the following, more details are pro- 
vided about each conformance class. A sketch of the protocol 
stack for the different classes is shown in Figure 41.1, which 
shows how Best-Effort (BE) and RT data exchanges at the 
application level are dealt with. 

Conformance Class 1 

The first kind of industrial Ethernet solutions is character- 
ized by the fact that both conventional Ethernet equipment 
( network interface controllers, switches, routers etc.) and the 
de facto standard TCP/IP protocol suite (including, possibly, 
User Datagram Protocol [UDP] [4], as well as other protocols 
commonly used in intranets) are used as the communication 
subsystem. Above it, purposely defined application layers are 
employed, which provide services tailored explicitly for the 
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FIG. 41.1 

Taxonomy of industrial Ethernet solutions. 


use in automated control environments. In several cases, in 
order to maintain a reasonable degree of compatibility with 
some specific kind of fieldbus, encapsulation is adopted 
for encoding directly the related application-layer services 
(through an adaptation layer). 

The benefits resulting from the choice of relying on 
TCP/IP are manifold: 

• Full interoperability with the office environment, fac- 
tory backbone, and the Internet as well is ensured, at 
least in theory. In reality, the traffic on the networks 
used at the field level has to be kept strictly under con- 
trol so as to preserve adequate performance and a rea- 
sonable degree of determinism. This also implies that 
the shop-floor has to be somehow decoupled from the 
factory backbone. Luckily, these goals can be achieved 
quite easily by using the traffic confinement mecha- 
nisms (IP multicast, VLANs, etc.) available in existing 
equipment (both routers and Ethernet switches). 

• Implementation costs decrease, at least in the initial 
development and design phase, since no custom hard- 
ware is required and not even low-level software has 
to be purposely rewritten (the existing drivers and 
socket-based protocol stacks are left untouched). It 
is worth remembering, however, that such additional 
costs, which are unavoidable in solutions belonging to 
the other conformance classes, are likely to become 
negligible, provided that many devices are built and 
sold. 

Networks belonging to such conformance class are, for 
example, EtherNet/IP [5,6], Modbus TCP [7], and Profinet 
CBA [8], 

Conformance Class 2 

In this case, despite only conventional Ethernet equipment is 
employed, suitable mechanisms are put into effect in order 


to improve either performance or determinism of the net- 
work — or both of them at the same time. 

Since the TCP/IP protocol stack has not been conceived 
to support RT communications, in order to reduce the local 
communication overheads, the exchange of process data takes 
place directly by using the communication services provided 
by the data-link layer (i.e., as close to the network controller 
as possible, depending on the specific platform adopted). So 
as to provide interoperability with applications and protocols 
developed for intranets, in most cases these solutions rely on 
a double protocol stack, namely, a TCP/IP-compliant and an 
RT stack. This means, that communication drivers and the 
protocol stack are likely required to be modified. 

Popular examples of solutions that fit in this conformance 
class of the taxonomy are Profinet 10 (RT version) [9] and 
Ethernet Powerlink [10]. In the first case, besides the adop- 
tion of a lightweight RT stack, determinism is improved by 
exploiting priorities as defined by the IEEE 802. IQ speci- 
fication [11], This kind of solutions provide a deterministic 
behavior “on the average,” that nevertheless may be adequate 
for many control applications found in automated factory 
environments. In the second case (i.e., Ethernet Powerlink) 
instead, an additional layer based on a master/slave access 
scheme is introduced between control applications (or, bet- 
ter, the application layer) and the Ethernet MAC (Medium 
Access Control) that permits this network to provide hard RT 
behavior using unmodified hardware. 

Although it is theoretically possible to interconnect net- 
works belonging to this second class directly to the factory 
backbone, doing so disrupts temporal properties and com- 
promises severely communication determinism. 

Conformance Class 3 

The last types of solutions are those that rely on modi- 
fied hardware in order to boost performance appreciably. 
Basically, two types of approaches have been commonly 
followed. 
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The first approach is to modify the network infra- 
structure so that it provides a “reserved lane” for hard RT 
traffic. For instance, purposely designed switches can be 
adopted that operate according to a Time Division Multiple 
Access (TDMA) principle. Such a solution is adopted in 
the Isochronous Real-Time (IRT) version of Profinet IO. In 
this case, a specific window (called phase , according to the 
Profinet terminology) is reserved in every transmission cycle 
to carry out isochronous frame exchanges. The schedule of 
such frames is planned in advance, before normal opera- 
tion is started. Moreover, they do not rely on the forwarding 
mechanism (based on destination addresses) implemented in 
conventional Ethernet switches for the transmission over the 
network. On the one hand this scheme achieves a fully deter- 
ministic behavior for isochronous traffic and, on the other, 
it still supports the transparent exchange of asynchronously- 
generated Ethernet frames for supporting, for example, con- 
ventional TCP/IP traffic. 

The second approach is to enhance performance is by 
using a modified network topology (for instance, a ring- 
shaped network) where devices are able to process Ethernet 
frames on-the-fly. Both EtherCAT [12,13] and SERCOS III 
[14] rely on this approach, and exploit an asymmetric con- 
figuration made up of exactly one network master and a set 
of slaves. In this case, the hardware of the network control- 
lers has to be modified so that pass-through delays are kept 
as low as possible (e.g., purposely designed slave control- 
lers are used in EtherCAT). This sometimes raises some 
doubts about the fact they can still be considered “Ethernet.” 
However, it is worth remembering that both the physical layer 
and the frame format remain exactly the same as Ethernet. In 
the case of EtherCAT, this means that conventional Ethernet 
equipment can be quietly used on the master side. 

These types of solutions usually feature the highest degree 
of communication efficiency when small-sized process data 
have to be exchanged, and guarantee very low jitters. This 
makes them suitable for specific application scenarios such 
as, for instance, motion control. On the other hand, it may 
happen that it is no longer possible to interconnect directly 
the held network to the factory backbone. In these cases, 
interconnection is only possible by using suitable gateways 
(e.g., switch ports), that in fact decouple the networks. 

How Ethernet and TCP/IP applied to various solutions 
such as, for example, MODBUS TCP, ETHERNET/IP, 
ETERNET Powerlink, and EtherCAT will be explained in 
detail in the following and examples will be given. 

MODBUS TCP 

Modbus [15] is a messaging protocol originally proposed 
by Modicon (today Schneider Electric) in 1979. It defines a 
set of application-layer services suitable for the use in indus- 
trial environments and is used for connecting a controlling 
device (e.g., the application master) to a number of slaves, 
also known as Remote Terminal Units (RTUs). Thanks to 


its inherent simplicity, which allows inexpensive implemen- 
tations, Modbus gained quickly wide acceptance, becoming 
a de facto standard in automated industrial environments. 
According to the taxonomy described at the beginning of this 
chapter, Modbus belongs to class 1. 

Nowadays, this protocol is supported by the Modbus 
Organization (http://www.modbus.org), an independent 
community of users and suppliers that takes care of main- 
taining the protocol and the related aspects, including device 
certification. Modbus specifications are currently available 
from their website free of charge. 

Network Architecture 

Modbus was initially conceived to rely on conventional serial 
lines for communication at the physical layer [16], accord- 
ing to the TIA/EIA 485 specification [17] (either two-wire 
or four-wire cabling is allowed). In 1999 another variant has 
been introduced, namely, Modbus TCP [7] that relies for 
communication directly on the standard TCP/IP protocol 
suite as described in reference [2], Ethernet is adopted at both 
the physical and data-link layers, which means Modbus TCP 
can be effectively considered an industrial Ethernet solution. 
This makes it possible to use the already existing Ethernet 
network controllers and transceivers to implement devices, as 
well as twisted pair cables and network equipment (switches) 
for the communication infrastructure. 

As the transmission services of TCP/IP are adopted to 
support the exchange of the Modbus messages over the net- 
work, it is possible, at least in theory, to broaden the plant 
under control by including parts that are not connected 
directly to the local network (remote control). Moreover, 
the whole protocol stack can be implemented in software 
inexpensively and effortlessly — at least, compared to other 
industrial Ethernet solutions — thus making Modbus TCP 
appealing in those cases where low cost and high flexibility 
are more important than performance. 

When implemented over TCP/IP, the Modbus messaging 
protocol relies on a plain client/server model. Any transac- 
tion is made up of a pair of distinct messages: a request sent 
by the client to the server and a response returned by the 
server in the opposite direction. Each device can provide 
either the client or the server side, or even implements both 
of them at the same time. 

Besides client and server devices, a third kind of devices 
is foreseen in the Modbus TCP network architecture, that is, 
gateways. Their purpose is to interconnect the TCP back- 
bone and serial lines, to which legacy Modbus devices are 
attached (see Figure 41.2). 

Adaptation and Transport Layers 

At the application layer, messaging services are encoded 
as Protocol Data Units (PDU), independent of the actual 
underlying transmission scheme. When PDUs are mapped 
on a specific kind of network (i.e., either a serial line or an 
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FIG. 41.2 

Network architecture of Modbus TCP. 



FIG. 41.3 

Encapsulation of Modbus PDUs in TCP. 


Ethernet-based TCP/IP network) some additional fields are 
added so as to form an Application Data Unit (ADU) suit- 
able for transmission on the given communication infrastruc- 
ture. As can be seen in Figure 41.3, every Modbus PDU is 
encapsulated in TCP by adding a field in front of it, called 
the Modbus Application Protocol (MBAP) header, which 
consists of 7 bytes. 

In particular, the MBAP header is made up of four sepa- 
rate fields, namely. Transaction Identifier (TI), Protocol 
Identifier (PI), Length (LEN), and Unit Identifier (UI). The 
transaction identifier (encoded on 2 bytes) is used for pairing 
messages. Its value is initialized on the client side, whereas 
the server simply copies this field from the request to the 
response message. Instead, the protocol identifier (2 bytes) 
has been included to allow different application-layer proto- 
cols to be multiplexed over the same network. In the case of 
Modbus, it is set to 0 by the client and is recopied unmodified 
by the server. 

Since TCP/IP models communications as a continuous 
stream of bytes, a length field (2 bytes) has been added that 
permits messaging services with a variable-sized payload to 
be dealt with properly. This also means that receivers can 
determine message boundaries accurately, therefore ensuring 
reliable synchronization between client and server. 

Finally, the slave address field previously found in 
legacy serial implementations is replaced here by the unit 
identifier field (1 byte). It can be used to deal with multiple 
devices that share the same IP address such as, for example. 


gateways used to connect the TCP/IP network to a legacy 
serial line. 

Before a client is enabled to communicate with a server, 
a TCP connection has to be established. To this extent, each 
device has to be listening on TCP port 502 (reserved to 
Modbus). In addition to port 502, other ports can be option- 
ally used. It is recommended that only one TCP connection 
be established with the same device, preferably by means of 
the automatic TCP connection management mechanism, and 
that the connection is kept open between subsequent message 
transactions. Moreover, it is required that each TCP segment 
embeds only one Modbus ADU. 

It is worth noting that the maximum PDU size allowed in 
Modbus is always 253 bytes, irrespective of the underlying 
network (e.g., serial line or TCP/IP over Ethernet). 

Application Layer 

Modbus is basically an application-layer messaging protocol, 
that is located conceptually at the upmost layer (7) in the ISO/ 
OSI communication model. Each PDU encodes exactly one 
service (either the request sent by the client or the response 
returned by the server). The type of the service is specified 
through suitable Function Codes (FCs) that are encoded on 1 
byte. Valid codes for FC range from 1 to 255, but the interval 
128-255 is reserved. 

Clients encode in the FC the action to be carried out by 
the server. If no error occurs, the server replies with the same 
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TABLE 41.1 

Data Model Used in Modbus 

Table 

Object Size 

Access 

Description 

Discrete inputs 

1 bit 

RO 

Process data that are provided by the I/O device 

Coils (discrete outputs) 

1 bit 

RW 

Process data that can be changed by the application program 

Input registers 

16 bits 

RO 

Process data that are provided by the I/O device 

Holding registers 

16 bits 

RW 

Process data that can be changed by the application program 


FC ( normal response). Otherwise, it sends back an excep- 
tion response where the most significant bit of the FC is set 
to logic 1, while the data field contains an exception code 
(encoded on 1 byte). A timeout should be set on the client side 
in order to avoid endless waiting. 

As described in Table 41.1, the data model that describes 
the interface Modbus servers offer through the network is 
based on four primary tables. Basically, tables differ in the 
size of the accessed objects (either one single bit or a whole 
16-bit word) and the access type, namely, Read/Write (RW) 
or Read-Only (RO). The different tables can be considered 
either as separate or overlapping entities, provided this makes 
sense at the application level for the specific device. In this 
second case, the application program executing on the client 
is given the ability to access the same piece of information in 
different ways (e.g., on a bit-by-bit basis or as a whole word). 

Each table may include up to 65,536 data items, each one 
identified by a logical reference number that is represented 
as an unsigned integer (starting from 0). In turn, logical refer- 
ence numbers are linked to addresses in the physical memory 
of devices. The mapping between the above data model and 
the specific features and behavior of devices is left com- 
pletely to device vendors. It is worth noting that every single 
read or write operation may actually span over a number of 
consecutive items. 

Function codes can be classified into three categories: 

• Public FCs: they are defined by the Modbus commu- 
nity, and are guaranteed to be unique, well defined, 
and validated. Their specification is public and suit- 
able conformance tests have been defined. Some FCs 
in this group have been reserved for future use. 

• User-defined FCs: they can be used by manufactur- 
ers to implement custom functions, not foreseen by the 
original specification. As a consequence, there is no 
guarantee that they are unique, and not even that some 
form of interoperability is possible. FCs in the ranges 
65-72 and 100-110 are reserved to this group. 

• Reserved FCs: they are used for legacy products, and 
therefore they are not available for public use. 

A number of fields may appear in the PDU after the FC, 
the exact number, size, format, and meaning depending on 
the specific service and direction (request or response). In 
data access services, they are usually aimed at encoding the 
process data to be exchanged (either values sensed by the 


server from the field or commands to be actuated coming 
from the client). In some cases, a 2 byte sub-function code is 
specified immediately after the FC to characterize in detail 
the behavior of the service (e.g., in the diagnostic case). In 
Table 41.2 the services offered by Modbus are listed, grouped 
according to their specific purpose (data access, diagnostics 
or other). 

ETHERNET/IP 

EtherNet/IP [5] is an industrial Ethernet network first intro- 
duced in 2001. Basically, it is an implementation of the 
Control and Information Protocol (CIP) [6] over Ethernet 
IEEE 802.3. CIP was previously used since the early 1990 
over different physical and datalink protocols (DeviceNet, 
ControlNet and, more recently, CompoNet) managed by 
the Open DeviceNet Vendor Association (ODVA, http:// 
www.odva.org). In EtherNet/IP, CIP is the application layer 
protocol, whereas either the TCP/IP-Ethernet or the UDP/ 
IP-Ethernet stacks are used as lower layer protocols (see 
Figure 41.4). According to the taxonomy described at the 
beginning of this chapter, EtherNet/IP belongs to class 1. 

The CIP Object Model 

Each device and connection that makes up an EtherNet/ 
IP industrial network is modeled by means of one or more 
objects. The object paradigm in CIP (see Figure 41.5) allows 
a high degree of abstraction and separation with the underly- 
ing protocol layers. Each object contains a set of attributes, 
specific values that differentiate an object from other objects 
of the same type and methods to read or modify attributes. 
Objects of the same type are instances of the same class. Each 
element of an object is uniquely identifiable and accessible. 

A real device using CIP is completely defined by a set 
of objects. Some of them are mandatory while others are 
optional. An Identity object, a Message Router object, a 
Network object and a Connection Manager object must be 
included in every CIP device. The Identity object contains 
data for the description of the device (i.e., vendor ID, date 
of manufacture, serial number, etc.). The Message Router is 
used for the device internal communications between objects. 
The Network object (in the case of EtherNet/IP this is a spe- 
cific object with the name “TCP/IP Interface object”) defines 
the parameters of the connection that are specific of the 
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TABLE 41.2 

Application-Layer Services Defined in Modbus 


Function Code 




Name 

FC 

Sub- Code 

Data access 1 bit access Physical discrete inputs 

Read discrete inputs 

02 


Internal bits or physical 

Read coils 

01 


coils 

Write single coil 

05 



Write multiple coils 

15 


16 bit access Physical input registers 

Read input register 

04 


Internal registers or physical 

Read holding registers 

03 


output registers 

Write single register 

06 



Write multiple registers 

16 



Read/write multiple registers 

23 



Mask write register 

22 



Read FIFO queue 

24 


File record access 

Read file record 

20 



Write file record 

21 


Diagnostics 

Read exception status 

07 



Diagnostic 

08 

00-18,20 


Get com event counter 

11 



Get com event log 

12 



Report slave ID 

17 



Read device identification 

43 

14 

Other 

Encapsulated interface transport 

43 

13,14 


CANopen general reference 

43 

13 
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FIG. 41.4 

The CIP stack using different physical and data link layers. 

lower layers (e.g., in the case of EtherNet/IP the IP address 
is stored, whereas in the case of DeviceNet, ControlNet and 
CompoNet the Network object contains other attributes). 
Finally, the Connection Manager object tracks and manages 
connections parameters like the type of connection, the pri- 
ority, the timeout, and so on. 

Some objects can be used in any device whereas oth- 
ers, that is, the Device-specific objects, can be used only 
for a specific device or a class of devices. All the object 
types listed previously are standardized in the EtherNet/IP 


specifications. Special-purpose features and behaviors of a 
device not covered by device-specific objects can be man- 
aged by creating vendor-specific objects. 

Connections Types 

CIP is a connection-oriented protocol. Indeed, before two 
devices are enabled to communicate, a connection must 
be established between them. The only exception is repre- 
sented by the Unconnected Message Manager (UCMM) 
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The CIP object model. 

object that can send a special type of messages, namely, the 
Unconnected Messages that can be routed without a connec- 
tion. Each connection is identified by a unique Connection 
ID, used and known by devices involved in the communi- 
cation. A connection is defined in CIP by means of three 
parameters: direction, transport class, and the event that trig- 
gers the production. 

The direction indicates whether the device is allowed to 
send packets (Client) or to receive them (Server). Transport 
classes can be subdivided into two groups: point-to-point and 
producer-consumer connections. Class 0 and class 1 connec- 
tions are typically based on a producer-consumer paradigm 
where the client, whenever an event is triggered, produces a 
packet. A server interested in these packets, after it has joined 
the connection, can read them. The difference between classes 
0 and 1 lies in the sequence number. Class 1 connections can 
detect packet loss or duplication by means of a sequence num- 
ber, whereas class 0 connections do not have this feature. 

On the other hand, class 2 and class 3 are used for point- 
to-point connections. In this case, a client produces a packet 
for a specific server. When a packet is received, the server 
replies to the client. In the case of class 2 connections the 
server replies immediately, without the intervention of the 
application. A value is sent back that should be made avail- 
able in advance by the application. Instead, when a packet is 
received in class 3 connections, the application is first noti- 
fied and, after the execution of its algorithm, it triggers the 
transmission of the response. Both class 2 and class 3 con- 
nections contain a sequence count useful to detect lost and 
duplicate packets. A scheme about the behavior of the differ- 
ent connection classes is shown in Figure 41.6. 

The production of a message by means of a client can be 
triggered in three different ways: 

• Cyclically by the expiration of a timer (Cyclic 

triggering) 

• Asynchronously, by a change of state detected by 

the application in one or more internal variables 

(Change-Of-State) 

• Directly by the application (Application) 


CIP uses two types of messages, namely, explicit mes- 
sages and I/O messages. They are listed in Table 41.3 along 
with the indication of the types of connections used. 

EtherNet/IP uses the TCP and the CIP encapsulation 
protocols to set up connections and to exchange non-time- 
critical data between devices using point-to-point connec- 
tions. Conversely, RT data are sent from a producer to one or 
more consumers through UDP, possibly using multicasting. 
In this case, the common packet format is adopted in order to 
reduce overheads. 

It is worth noting that EtherNet/IP is not considered 
a hard RT protocol, because queuing of UDP packets in 
switches may led to unpredictable delays and non-negligible 
jitters in the delivery time of packets. 

Explicit Messages 

Explicit messages are non-time-critical messages, which 
are usually adopted either for the transmission of non- 
time-sensitive (potentially large) data or to set up con- 
nections. Typical explicit connections are those used for 
Unconnected Messages, as well as class 2 and class 3 con- 
nections. Since they are based on a client/server commu- 
nication paradigm, they are used to convey point-to-point 
messages. Explicit connections require a different connec- 
tion ID for each direction, a source address and a desti- 
nation address. Explicit messages are encoded by means 
of the CIP Encapsulation protocol and use TCP/IP and 
Ethernet as protocol stack. 

Figure 41.7 shows the size of the different headers 
involved in the encapsulation of an explicit message. TCP 
is optimized for accurate delivery. This ensures that a mes- 
sage is eventually delivered to the destination but without any 
guarantees on timing constraint. 

CIP encapsulation protocol: the CIP encapsulation protocol 
defines a 24-byte header followed by a data field including 
up to 65,511 bytes. The first 2 bytes of the header identify 
a command. The other fields are Length (the length of the 
data field). Session Handle (used to identify a session). Status 
(indicates if a receiver has correctly executed the requested 
command), Sender Context (used to match requests with the 
associated responses), and Options Flags (not standardized 
yet). Usually, encapsulated packets are sent over TCP, with the 
exception of the ListServices, Listldentity and Listlnterfaces 
commands, used to discover devices services and interfaces 
that can be sent either via TCP or UDP. 

I/O Messages 

I/O messages are used for time critical (RT) communications 
between a producer and one or more consumers. They rely on 
CIP class 0 or CIP class 1 connection and are sent using the 
UDP/IP-Ethernet stack. Since they are exchanged according 
to the producer-consumer paradigm, they may use multicast 
addressing in order to distribute the produced data to all the 
consumers that require them at the same time. 
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Behavior of connection classes. 


Data transmitted by means of I/O messages are consid- 
ered to be time-critical (even though hard RT communi- 
cation is not supported). For this reason, they are not sent 
through the combination of the CIP encapsulation protocol 
and TCP, which introduces a 44-byte overhead (24 deriving 
from encapsulation and 20 from TCP), but using the more 
efficient Common Packet Format (CPF) over UDP The over- 
head introduced in this case is limited to 18 bytes (10 from 
the CPF and 8 from UDP). 


In Figure 41.8, the encapsulation of the I/O messages and 
the size of the different headers involved in the encapsulation 
are shown. 

Common packet format: the CPF is composed by a 2 bytes 
Item Count and is followed by a list of at least two items. In 
turn, each item is made up of a header with two fields: Type 
ID (2 bytes — it indicates the type of data contained: if it con- 
tains an address, the type of address; if it contains data, the 
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TABLE 41.3 

Messages and Connections Taxonomy 



Message Type 

Connection Type 

Protocol Stack 

Communication Paradigm 

Characteristics 

Explicit 

UCMM 
Class 2 
Class 3 

Encapsulation 

TCP 

IP 

Ethernet 

POINT-TO-POINT 

Useful to configure connections 
and to send no time critical data 

I/O 

Class 0 
Class 1 

Common packet 
Format 
UDP 
IP 

Ethernet 

PRODUCER-CONSUMER 

For RT and time critical data 


Ethernet 

header 

IP 

header 

TCP 

header 

Encapsulation 
protocol header 

(14 bytes) 

(20 bytes) 

(20 bytes) 

(24 bytes) 


Command (2 bytes) 
Length (2 bytes) 

Session handle (4 bytes) 
Status (4 bytes) 

Sender context (8 bytes) 
Options 


Encapsulated 

data 

(from 0 to 
65,511 bytes) 


C 

R 

C 


FIG. 41.7 

Explicit messages encapsulation. 
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FIG. 41.8 

I/O messages encapsulation. 

type of data) and Length (2 bytes — it indicates the length of 
the data field). After the header there is an optional data field, 
which is present only if Length > 0. 

ETHERNET POWERLINK 

Ethernet Powerlink (EPL) is a popular industrial Ethernet 
network that, according to the taxonomy introduced at the 
beginning of this chapter, belongs to class 2. 

EPL makes use of IEEE 802.3 standard Ethernet, with- 
out changing any of its basic features, and extends it in 
order to obtain communication synchronization between 
the network nodes, cyclic transmission of time-critical data 
characterized by low and predictable delays and asynchro- 
nous (on request) transmission of less time-critical data. 

These features make the EPL network suitable for indus- 
trial communication, since they allow the network to meet the 
reliability and tight timing requirements typical of industrial 
automation applications (e.g., motion control applications), 
as well as they allow the user to continue to use standard 
Ethernet infrastructure components and testing and measure- 
ment devices. 


The first version of Ethernet Powerlink was developed 
by B&R [18] in 2001. In 2003, the Ethernet Powerlink 
Standardization Group, EPSG (http://www.ethernet- 
powerlink.org), which is currently managing the network 
development, published the EPL specifications as an open 
standard, naming it Ethernet Powerlink version 2.0 [4]. 
Subsequently, this version of EPL was included in the IEC 
61784 International Standard [14], as Communication Profile 
(CP) #1 of the Communication Profile Family (CPF) #13. 
Currently, a more recent version of the EPL specifications 
[19] is available on the EPSG website. 

Network Architecture 

With reference to the ISO/OSI model [20], the network archi- 
tecture of EPL is illustrated in Figure 41.9. 

As can be observed, EPL defines a Data Link Layer 
(EPL DLL) on the top of the IEEE 802.3 standard Ethernet 
Physical layer and Medium Access Control (MAC) sub-layer. 

Moreover, an application layer protocol, based on the 
widespread CANopen standard [21], has been placed on the 
top of the EPL DLL. For this reason, EPL is also known 
as “CANopen over Ethernet.” Using CANopen at the 


© 2012 by Bela Liptak 


41 Industrial Ethernet and TCP/IP-Based Systems 645 


EPL 

Other high level 

Application layer 

protocols 


u 


t 



Application 


Session 


Transport 


Network 


EPL 

Data link layer 


IEEE 802.3 Ethernet MAC 


IEEE 802.3 Ethernet 
physical layer 


Data link 


Physical 


FIG. 41.9 

EPL network architecture with reference to the ISO/OSI model. 


application layer guarantees the compatibility of the EPL 
network with a large number of already deployed commu- 
nication systems. 

Physical Layer and MAC Sub-Layer 

The EPL physical layer is defined as one of the Ethernet 
physical layer; in particular the EPL specifications indicate 
100BASE-X (copper and fiber) half-duplex as transmis- 
sion mode and standard patch cables (twisted pair, S/UTP, 
AWG26) with either RJ-45 or M12 connectors for the con- 
nection of EPL devices. The EPL specifications recommend 
the IAONA standard [22] for the installation guidelines. 

EPL makes use, without applying any change, also of 
the standard Ethernet MAC sub-layer. The algorithm used 
by EPL devices to access the transmission medium is the 
well-known CSMA/CD (Carrier Sense Multiple Access with 
Collision Detection). 

Nonetheless the EPL DLL manages the network traffic, 
using a so called Slot Communication Network Management 
(SCNM) technique, with the result that isochronous and 
asynchronous data are transmitted by each EPL device in 
dedicated time slots (see Figure 41.10) and it is guaranteed 
that only one device at a time accesses the transmission 
medium. Consequently, the SCNM technique allows EPL to 
avoid frame collisions and to achieve, at the same time, pre- 
cise communication timing. 
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FIG. 41.10 

EPL slot communication network management (SCNM). 


EPL Data Link Layer Protocol 

According to the EPL specifications, an EPL network can 
operate in two different modes: 

1. Powerlink mode: where the communication follows 
the EPL DLL rules and the transmissions are sched- 
uled in specific time slots 

2. Basic Ethernet mode: where the communication fol- 
lows the rules of IEEE 802.3 Ethernet 

When the network operates in the Powerlink mode, the deter- 
minism is achieved by a pre-organized message exchange: 
time is divided in cycles comprising an isochronous and an 
asynchronous phase, during which each transmission has a 
dedicated time slot, as in Figure 41.10. 

The EPL standard defines two types of nodes, namely, 
the Managing Node (MN) and the Controlled Nodes (CNs). 
The MN is the only station, within the EPL network, that 
can send frames independently and gives the other stations 
the permission of sending their own frames; all the other 
stations, called CNs, are passive bus devices and can only 
transmit within the communication slots assigned them by 
the MN. Only one MN is allowed within an EPL network, 
while it can comprise up to 240 CNs. 

Typically, the MN is the “controller” device of an indus- 
trial automation system (i.e., the device that executes the 
automation tasks), while the CNs are held devices such as 
sensors, actuators, etc. 

Several EPL compliant devices, from different vendors, 
are currently available on the market encompassing most of 
the components used in industrial automation systems such 
as, for example, Programmable Logic Controllers (PLCs), 
Computer Numerical Control (CNC), valves, pumps, I/O sys- 
tems, and electrical drives. Moreover, since April 2008 the 
source code for implementing either an EPL MN or CN on a 
programmable device is freely accessible [23]. 

Powerlink Cycle 

The communication between the nodes of an EPL network 
occurs on the basis of a cycle, namely, the Powerlink cycle 
shown in Figure 41.11, which is repeatedly executed by EPL 
nodes. 

The duration of the EPL cycle, T PC , is established by the 
user during the network configuration phase and is main- 
tained constant. 

As shown in Figure 41.11, a Powerlink cycle consists of 
three different phases: (1) isochronous phase, (2) asynchro- 
nous phase, and (3) idle phase. 

The Isochronous phase of an EPL cycle starts with the 
beginning of the cycle and ends when all time-critical data 
transfers between the EPL nodes have been performed. 

Specifically, at the beginning of each EPL cycle, the MN 
broadcasts (via Ethernet multicast) a Start of Cycle (SoC) 
frame to all the active CNs connected to the EPL network. 
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FIG. 41.11 

Example of Powerlink cycle. 


The send and receive time of the SoC frame is the basis for 
the synchronization of the nodes. 

The SoC is the only EPL periodic frame (i.e., it is the only 
one independently generated and transmitted over the net- 
work every T PC ). All the other EPL frames are event-driven, 
generated in response to predefined events, such as the recep- 
tion of a particular frame or the expiration of a particular 
time interval, etc. 

After the SoC frame has been sent and the synchroniza- 
tion between the nodes has been achieved, the cyclic time- 
critical data exchange takes place by means of a standard 
polling procedure. More in detail, the MN polls each active 
CN connected to the network by sending it a Poll Request 
(PReq) frame and by waiting for a Poll Response (PRes) 
frame before moving to the next CN. 

The reception of a PReq frame by a particular CN indi- 
cates the beginning of the time slot specifically dedicated to 
data transfer from that CN. A PReq frame is always a uni- 
cast Ethernet frame, since only the target CN can receive 
it, which contains data addressed by the MN to the target 
CN. On the other hand, PRes frames are always multicast 
Ethernet frames, such that each CN could receive the iso- 
chronous data sent over the network by the other CNs. This 
procedure allows producer-consumer relationships between 
the EPL nodes of the network. 

When a CN receives a PReq frame, it must answer with a 
PRes frame. The MN waits until the specific PRes frame has 
been received before polling the next CN. If a PRes frame 
does not arrive within a predefined amount of time, namely, 
the Powerlink timeout specified by the user during the net- 
work configuration phase, the MN moves to the next CN. If a 
particular CN does not respond within a predefined number 
of consecutive Powerlink cycles, the MN simply removes it 
from the polling list. 

Once all the network CNs have been polled, the MN can 
broadcast a further PRes frame in order to transmit data rel- 
evant for groups of CNs (it is worth observing however that 
such a function is not necessarily supported by MNs). 

Subsequently, the asynchronous phase is entered and the 
MN sends a Start of asynchronous (SoA) frame to one of 
the CNs. In order to receive such a frame, the addressed CN 
had to make a specific asynchronous transmission request 
during one of the previous isochronous phases. Two types 
of asynchronous frames are allowed: ASnd frames and 


standard Ethernet frames. ASnd frames use the Powerlink 
addressing scheme and can rely on either unicast or broadcast 
transmissions. 

In the absence of requests for asynchronous transmission, 
the MN sends a SoA frame without assignment of the right to 
transmit to any CN. The SoA frame begins the Asynchronous 
phase and lets all the CNs know that the isochronous phase 
has been concluded. 

Finally, the Idle phase represents the time between the 
end of the asynchronous phase and the beginning of the next 
Powerlink cycle. During the Idle phase all the EPL network 
nodes simply wait for the next SoC frame. 

The Powerlink cycle represents the minimum sample 
time for the time-critical data that are collected by the CNs 
and read every cycle by the MN. For this reason it is impor- 
tant to keep the start time of a Powerlink cycle as precise as 
possible. 

During the network configuration phase, the user can set 
the value of Tpc'i in order to correctly configure the EPL net- 
work, such a value has to be chosen carefully, taking into 
account the times necessary to send the SoC and the PReq 
and PRes to from the active CNs, as well as the elaboration 
delays typical of each node, such that the cycle time is not 
exceeded during the network operation phase. 

CN Communication Classes 

The EPL specifications define two communication classes 
in order to possibly achieve different polling periods for the 
CNs. In particular, a CN can be polled in two ways: 

1. Continuous that is it is polled by the MN in every 

cycle 

2. Multiplexed that is it is polled by the MN every n 

cycles 

The possibility of defining the communication class of 
a CN allows the user to realize EPL networks with a large 
number of nodes, maintaining low values of Tpc- An example 
of multiplexing is provided in Figure 41.12. 

It is worth noticing that, although the multiplexed nodes 
are not polled in every cycle, they can in any case receive 
data from the other CNs in each cycle since PRes frames are 
transmitted on the network via Ethernet multicast. 
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FIG. 41.12 

Example of multiplexed Powerlink cycle. 
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EPL frame structure. 


EPL Frames Structure 

EPL frames are encapsulated in the Data field of standard 
Ethernet frames (see Figure 41.13). 

The Ethernet Type held of the frame in this case con- 
tains the hexadecimal value 88AB. As can be seen in Figure 
41.13, an EPL frame is composed of five fields: the first octet, 
namely, “Message Type” specifies the type of the EPL frame. 
To this regard, Table 41.4 illustrates the association between 
the value of this held and the EPL frames. The second and 
third octets contain, respectively, the source and the desti- 
nation node EPL addresses, while the remaining octets are 
reserved to the data to be exchanged. 

Network Configuration and Topology 

The EPL specihcations strongly recommend the use of hubs 
as interconnection devices between different segments of an 


TABLE 41.4 

Message Type Field Possible Values 


EPL Frame Type Hexadecimal Value of Message Type Field 


SoC 

01 

PReq 

03 

PRes 

04 

SoA 

05 

ASnd 

06 


EPL network. Indeed, hub devices guarantee low commu- 
nication delays (less or equal to 460 ns) and jitters (less or 
equal to 70ns); in some cases a hub can be integrated into 
the EPL node. 

Switch devices could also be used for the interconnec- 
tions between the EPL segments but, in this case, additional 
delays and jitters should be considered during the network 
conhguration phase. 

Moreover, since frame collisions are not possible, the 
IEEE 802.3 standard constraint about a 5.12 |is maximum 
round trip signal runtime does not apply to EPL networks, 
and line topologies with large numbers of nodes, typi- 
cal of industrial automation applications, are thus possi- 
ble. Other common topologies like stars, trees, or hybrid 
tree-line configurations are allowed as well, as shown in 
Figure 41.14. 

EPL Application Layer Protocol 

As previously mentioned, the EPL specifications define an 
application layer protocol based on the well known CANopen 
standard. 

In particular, the application layer protocol of EPL pro- 
vides the mechanisms for configuring and exchanging time- 
critical data as well as the mechanism for synchronizing EPL 
nodes. 

The functionalities offered by the EPL application layer 
to a generic application are logically identified by service 
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FIG. 41.14 

Example of EPL network topology. 

objects. Each service object offers a particular functionality 
and all the related services. The applications interact among 
each other by invoking the services of a service object in the 
EPL application layer. 

EtherCAT 

Ethernet for Control Automation Technology, EtherCAT, 
is an open standard currently managed by the EtherCAT 
Technology Group, ETG (http://www.ethercat.org). The 
EtherCAT specification has been recently included in the 
International Standards IEC 61158 [24] and IEC 61784 [14], 
EtherCAT is based on a master-slave paradigm, where 
only one master is allowed in the network, and uses a ring 
topology at the physical level. It can interoperate with both 
common TCP/IP-based networks and other Ethernet-based 
solutions, such as EtherNet/IP or Profinet. According to 
the taxonomy introduced at the beginning of this chapter, 
EtherCAT belongs to class 3. 


Network Architecture 

EtherCAT nodes are arranged in a physical ring, which 
originates from the master, passes through all the slaves, 
and is eventually redirected to the master, as shown in 
Figure 41.15. 

The EtherCAT master processes data using standard 
hardware (full-duplex Ethernet network interface controllers) 
and dedicated software (e.g., Beckhoff TwinCAT), but it can 
be used also with open source solutions based on Linux-like 
operating systems. On the other hand, specifically designed 
hardware has to be used for the slaves. The master node 
completely controls traffic over the network by initiating all 
transmissions. Every slave, when receiving a datagram, pro- 
cesses it and then forwards it to the next slave in the physical 
ring, as described in Figure 41.15. Such an operation is car- 
ried out “on-the-fly,” ensuring very fast transmission times. 

In order to further improve communication efficiency, a 
Fieldbus Memory Management Unit (FMMU) is provided in 
each slave device that enables portions of data included in 
the frame to be read or written while it is being forwarded to 
the next device. 

EtherCAT supports two different types of physical layer: 
Ethernet and EBUS. The former is used for connecting to an 
external Ethernet network according to IEEE 802.3 standard. 
Indeed, an EtherCAT network (a segment, in the EtherCAT 
terminology) can be seen as a single, large, Ethernet device 
that receives and sends Ethernet frames. On the other hand, 
this “device” is not made up of a single Ethernet controller, 
but includes a (possibly large) number of EtherCAT slaves. 

Conversely, EBUS is a physical layer designed to reduce 
pass-through delays inside the nodes. Typically, frames are 
only delayed by 60-500 ns, while a higher delay (about 1 ps) 
is introduced by Ethernet interfaces between segments. 

EtherCAT uses the Manchester (Biphase L) encoding 
and encapsulates frames between Start-of-Frame (SOF) and 
End-of-Frame (EOF) identifiers. The beginning of a frame 
is defined by a Manchester violation where a positive level is 
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FIG. 41.15 

EtherCAT typical topology, with the “on-the-fly” processing. 
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followed by a “1” bit: the first bit of the Ethernet preamble. 
Then, the whole Ethernet frame is transmitted (including the 
Ethernet SOF at the end of the preamble, up to the CRC). The 
frame ends with a Manchester violation where a negative level 
is followed by a “0” bit: the first bit of the IDLE phase. It uses 
Low Voltage Differential Signaling (LVDS) and the data rate 
is 100 Mbit/s accomplishing the Fast Ethernet specification. 

The maximum number of addressable devices is 2 16 for 
each segment, while the distance between any two adjacent 
nodes (i.e., the cable length) can be up to 10 m for EBUS and 
up to 100 m for Ethernet connections. 

Data Link Layer 

The Medium Access Control (MAC) mechanism is based 
on the master-slave principle, where the master node sends 
Ethernet frames to the slave nodes over the physical ring and 
each slave extracts data from (and inserts data into) the pay- 
load of these frames. 

The frames sent over the network are standard Ethernet 
frames where the data field encapsulates the EtherCAT 
frame, as shown in Figure 41.16. This latter is made up of 
a header and one or more EtherCAT datagrams or PDUs 
(Protocol Data Units). In this way, it is possible to obtain a 
more efficient use of the large Ethernet data field available. 
EtherCAT PDUs are packed together without inter PDU 
gaps. The frame is completed with the last EtherCAT PDU, 
and, in case the frame size is less than 64 octets, it is padded 
to 64 octets in length. Each EtherCAT PDU contains three 
fields, namely, header, data and Working Counter (WC). At 


the end of the frame, the standard Ethernet CRC is used to 
check the integrity of messages. 

The whole EtherCAT segment, from the point of view of 
the master, is seen as a single Ethernet device that receives 
and sends standard Ethernet frames with the EtherType field 
set to 0 x 88A4 to distinguish it from other Ethernet frames. In 
this way, EtherCAT can coexist with other Ethernet protocols. 

Slave nodes recognize the relevant commands and exe- 
cute them accordingly while the frames are passing through. 
The last EtherCAT slave device in the segment redirects the 
fully processed frame back to the previous slave in the ring 
and the same occurs for each slave, up to the master. This 
procedure is based on the full-duplex mode of Ethernet, 
which allows communications to take place in both direc- 
tions independently. 

Several EtherCAT datagrams can be embedded within 
the same Ethernet frame, each one addressing different 
devices and/or memory areas. As shown in Figure 41.16, the 
EtherCAT datagrams are transported in two different ways: 

1. Directly in the payload of the Ethernet frame 

2. Within the payload of a UDP datagram carried via IP 

The first variant is limited to the use within one Ethernet 
subnet, since associated frames are not relayed by routers. 
The Ethernet MAC address of the first node in the segment is 
used for addressing the EtherCAT segment. 

The second variant (via UDP/IP) implies a slightly larger 
overhead (because of the IP and UDP headers), but for less 
time-critical applications such as process control, it enables 
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FIG. 41.16 

EtherCAT frame structure. 
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the use of IP routing. On the master side any standard UDP/ 
IP implementation can be used in this case. 

Addressing 

EtherCAT supports different addressing modes for accessing 
the slaves, as shown in Figure 41.17. The 32 bit address field 
within the EtherCAT PDU header is used for either physical 
node addressing or logical addressing. 

Physical Addressing In the physical addressing scheme, the 
32 bit address field within each EtherCAT PDU is split into 
a 16 bit slave address and a 16 bit physical address within 
the slave device, thus leading to 2 16 slave addresses, each 
one with an associated 16 bit local address space. It is worth 
noting that with device addressing, each EtherCAT PDU 
can uniquely address one single slave device. This mode is 
mainly used for transferring parameterization information to 
devices. There are two different device addressing mecha- 
nisms, namely, position addressing and node addressing. 

1. Position addressing: This mode is used to address 
each slave device via its physical position within the 
network segment. Each slave device increments the 16 
bit address field as the datagram transits through the 
device; the slave that receives a frame with an address 
field equal to 0 is the one being addressed. At the 
beginning, that field is set by the master to the negative 
position of the slave in the loop (the master position is 
marked by “0”). Due to the mechanism employed to 
update the address while the frame is passing through 
the node, the slave device is said to have an auto-incre- 
ment address. Position Addressing should be used 


during the start up phase of the EtherCAT system only 
to scan the bus. Moreover, it can be adopted occasion- 
ally to detect newly attached slaves. 

2. Node addressing: In this mode, slaves are addressed 
via configured node addresses assigned by the mas- 
ter during the start-up phase. Thus, even if the seg- 
ment topology is changed or devices are added or 
removed, the slaves can still be addressed via the 
same configured addresses. Node addressing is typi- 
cally used for registering access to individual and 
already known devices. The address may be either 
assigned by the master (Configured Station Address) 
or read from the internal EEPROM that can be 
changed by the slave application (Configured Station 
Alias address). 

Logical Addressing (FMMU) Using the datagram structure 
described above, several EtherCAT devices can be sepa- 
rately addressed via a single Ethernet frame, each one by 
means of one EtherCAT datagram. However, for small- 
size input terminals, for example 2 bit input devices that 
map precisely 2 bit of user data, the overhead of a single 
EtherCAT command might be excessive. The Fieldbus 
Memory Management Unit (FMMU) lessens this prob- 
lem. Indeed, similarly to the Memory Management Units 
(MMU) in modern processors, the FMMU converts a logi- 
cal address into a physical one via an internal table, support- 
ing bit-wise mapping. This enables, for example, the 2 bits 
of an input terminal to be inserted individually anywhere 
within a logical address space. If an EtherCAT command 
is used to read or write a certain memory area, instead of 
addressing a particular EtherCAT slave, the 2 bit input ter- 
minal inserts its data in the right place within its data area. 
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EtherCAT addressing and datagram structure. 
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FIG. 41.18 

FMMU mapping example. 


The same can be done by other terminals that are addressed 
through their FMMUs. 

This allows the use of logical addressing for data seg- 
ments that span several slave devices. An example is provided 
in Figure 41.18, where one command (datagram 1) addresses 
data (data 1) within two arbitrarily placed slaves (Slave 1 and 
Slave m). The access type supported by an FMMU is config- 
urable as read, write, or read/write. The FMMU configura- 
tion is performed by the master device and transferred to the 
slave devices during the start-up phase. When an EtherCAT 
datagram with logical addressing is received, the slave device 
checks whether one of its FMMU entities exhibits an address 
match. If this is the case, it either inserts its data into the 
associated position of the data field of the datagram (read 
operation) or extracts data from the associated position (write 
operation). 


Commands 

Each EtherCAT PDU consists of an EtherCAT header, the 
data area and the working counter, as already described in 
Figure 41.18. 

In particular, each datagram contains the fields listed in 
Table 41.5. 

The parameter CMD encodes the service command. 
Different types of commands can be used for optimizing 
read and write operations on the slaves that can be classi- 
fied depending on the access type. They are listed below. An 
accurate description of them can be found in the EtherCAT 
specification documents. 

• Read and/or Write 

• Broadcast Read/Write 

• Read/Multiple Write 


TABLE 41.5 

Fields of the EtherCAT Datagram 


CMD 

Unsigned8 

EtherCAT command type 

IDX 

Unsigned8 

Index for identification of duplicates(lost) datagrams 

Address 

DWORD 

Address (auto increment, configured station address, or logical address) 

T.F.N 

Unsigned 1 1 

Length of the DATA field 

R 

3 bit 

Reserved 0x00 

C 

1 bit 

Circulating frame 

0x00: Frame is not circulating 

0x01: Frame has circulated once 

M 

1 bit 

0x00: last EtherCAT PDU in EtherCAT frame 
0x01: EtherCAT PDU in EtherCAT frame follows 

IRQ 

WORD 

External EtherCAT event request registers of all slaves combined with a logical OR 

DATA 

OctetString LEN 

Data 

WC 

WORD 

Working counter 
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The IDX field is the identifier of the datagram; it is 
left unchanged by the slaves. The parameter LEN con- 
tains the size in byte of the data to be read or written. The 
field C is used in the case of a network with a link failure 
between two slaves, whereas M specifies whether or not 
the EtherCAT PDU is the only one in the frame. The IRQ 
field is used to inform the EtherCAT master of slave events. 
The DATA field contains the process data that can be read 
or written. 

The last field is the Working Counter. This field is 
used to count the number of devices that were success- 
fully addressed by an EtherCAT datagram. Each addressed 
slave increments the working counter in hardware. Because 
each datagram has an expected WC value computed by the 
master, the valid processing of datagrams can be checked 
by comparing the received WC with the expected value. 
This is actually done by the master at each reception of the 
EtherCAT datagram. 

Distributed Clock 

An important mechanism included in the EtherCAT protocol 
is the Distributed Clock synchronization, used to enable all 
devices (master and slaves) to share the same System Time 
with a precision better than 1 |is. The main features of this 
mechanism are as follows: 

• Generation of synchronous output signals 

• Precise time stamping of input events 

• Synchronous Digital Output updates 

• Synchronous Digital Input sampling 

Typically, the clock reference (System Time) is set by the 
first slave with Distributed Clock capability after the master 
within the network segment. 

The propagation delays, local clock source drifts, and 
local clock offsets are taken into account for the clock syn- 
chronization. All settings are done during the clock synchro- 
nization process, which is made up of three steps: 

1. Propagation delay measurement: the master sends 
a synchronization datagram at certain intervals and 
each slave stores the time of its local clock twice: once 
when the message is received for the first time and 
once when it is received on the return path (accord- 
ing to the EtherCAT ring topology). Then, the master 
reads all these time stamps and computes the propaga- 
tion delays between all the slaves. 

2. Offset compensation to System Time: because the local 
time of each device is basically a free running counter, 
a compensation mechanism is necessary. To obtain the 
same absolute time, all the differences between the 
System time and the clock of every slave are computed 
by the master. Then, the offset time is written to a spe- 
cific slave register (System Time Offset). Each slave 
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FIG. 41.19 

EtherCAT state machine. 

computes its local copy of the System Time using its 
local time and the local offset value. 

3. Drift compensation to System Time: after the delay 
between the System Time and each slave clock has 
been measured, and the offset has been compensated, 
the natural drift of every local clock has to be con- 
nected by a time control loop. This mechanism read- 
justs the local clock by regularly measuring such 
difference. 

EtherCAT State Machine 

The EtherCAT State machine, shown in Figure 41.19, is 
responsible for the coordination of the master and the slaves 
at start up, as well as during normal operation. 

State changes are typically initiated upon requests issued 
by the master. They are acknowledged by the local appli- 
cation after the associated operations have been executed. 
Simple devices without a microcontroller can be config- 
ured to use EtherCAT State Machine emulation. These 
devices simply accept and acknowledge any state change 
automatically. 

As shown in Figure 41.19, there are four basic states an 
EtherCAT device shall support, plus one optional, namely, 
the Bootstrap state (the only purpose of this state it to allow 
for the download of device firmware). 
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